-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arbitrum gateways #57
base: master
Are you sure you want to change the base?
Conversation
7b7a7ca
to
34ed3b8
Compare
@@ -16,14 +16,12 @@ import {IXCAmple} from "../../_interfaces/IXCAmple.sol"; | |||
* the xc-ample contracts. | |||
* | |||
*/ | |||
contract MaticXCAmpleRebaseGateway is Layer2RebaseGateway, FxBaseChildTunnel { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially assumed we could abstract all L2s to implement the same gateway interface, however there are operational differences between L2s which prevent this.
eg) Matic doesn't charge a ETH fee to send data from ethereum to matic but Arbitrum does. Arbitrum expects the caller to "pre-pay" the storage and execution cost of the cross chain transaction and thus has some additional parameters.
Leaning toward defining separate gateway interfaces for each bridge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. Unfortunately I think it's unlikely these bridges will be similar enough to abstract away completely.
acd29af
to
77bd9b3
Compare
77bd9b3
to
5b3d984
Compare
IERC20(_l1Token).safeTransferFrom(from, address(this), _amount); | ||
IERC20(_l1Token).approve(vault, _amount); | ||
|
||
ITokenVault(vault).lock(_l1Token, address(this), _amount); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do this to keep the audit trail on the vault. Explicitly calling lock
over just transferring directly into the vault logs the GatewayLocked
event.
https://github.com/ampleforth/cross-chain-ample/blob/master/contracts/base-chain/TokenVault.sol#L31
However I wonder if the GatewayLocked
and GatewayUnlocked
events are redundant as one could always reconstruct the same information using merely the token transfer logs.
If so we can safeTransferFrom
the user's wallet directly into the vault which is cleaner and more gas efficient.
AMPL Arbitrum Bridge gateways.
To test the UI: